home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Cream of the Crop 25
/
Cream of the Crop 25.iso
/
faq
/
amsls497.zip
/
AMOSLIST
/
000002_amos-request@svcs1.digex.net_Wed Apr 2 05:03:21 1997.msg
< prev
next >
Wrap
Internet Message Format
|
1997-05-01
|
10KB
Received: from svcs1.digex.net (svcs1.digex.net [204.91.197.224])
by mail1.access.digex.net (8.8.5/8.8.5) with ESMTP id FAA22208
for <mcox@access.digex.net>; Wed, 2 Apr 1997 05:03:20 -0500 (EST)
Received: (from daemon@localhost)
by svcs1.digex.net (8.8.5/8.8.5) id DAA16303
for amos-out; Wed, 2 Apr 1997 03:33:31 -0500 (EST)
Received: from mail2.access.digex.net (mail2.access.digex.net [205.197.247.3])
by svcs1.digex.net (8.8.5/8.8.5) with ESMTP id DAA16300
for <amos-list@svcs1.digex.net>; Wed, 2 Apr 1997 03:33:30 -0500 (EST)
Received: from f7.hotmail.com (F7.hotmail.com [207.82.250.18])
by mail2.access.digex.net (8.8.5/8.8.5) with ESMTP id DAA03772
for <amos-list@access.digex.net>; Wed, 2 Apr 1997 03:33:29 -0500 (EST)
Received: (from root@localhost) by f7.hotmail.com (8.7.5/8.7.3) id AAA22712; Wed, 2 Apr 1997 00:15:50 -0800 (PST)
Date: Wed, 2 Apr 1997 00:15:50 -0800 (PST)
Message-Id: <199704020815.AAA22712@f7.hotmail.com>
Received: from 193.214.146.22 by www.hotmail.com with HTTP;
Wed, 02 Apr 1997 00:15:50 PST
X-Originating-IP: [193.214.146.22]
From: " Ragnar Fyri" <ragnar_fyri@hotmail.com>
To: amos-list@access.digex.net
Subject: Transition effects part 5 etc.
Content-Type: multipart/mixed; boundary="====================987654321_0==_"
X-Attachment: Textfile.txt
Status: RO
X-Status:
--====================987654321_0==_
Content-Type: text/plain
---------------------------------------------------------
Get Your *Web-Based* Free Email at http://www.hotmail.com
---------------------------------------------------------
--====================987654321_0==_
Content-Type: text/plain; name="Textfile.txt"
Content-Disposition: attachment; filename="Textfile.txt"
Here we go again. Another month has come to an end, and soon I can down-
load the March archive and see if anyone ignored what I said about contact-
ing me directly because I'm not on the list. [And don't tell me how to
subscribe, I have chosen not to because downloading and processing all the
induvidual messages is to much hassle. The only problem with what I'm doing
now is that attached files come out as Base64, whatever THAT is. Anyone
know how to convert those cryptic text chunks back into their original
form? (And if it can't be done, what's the point with including them in the
archive in the first place?)
Talking of archives, here's a little batch file I put together for pro-
cessing them.
;Type f.ex. "ual 06 96" to unpack 0696.lhz to 9606
lha e <mo><ye>.lzh AMOSLIST
rename AMOSLIST <ye><mo>
ask "Delete <mo><ye>.lzh? "
if warn
delete <mo><ye>.lzh
endif
This unpacks just the main file from the archive, renames it and deletes
the archive after asking just to be sure. Renaming it means I can keep all
the monthlies in the same directory (and won't have to check the file date
to see which is which either), and switching year and month around means
the files will get listed in chronological order when sorted "alphabeti-
cally" (On Aminet all the January files are grouped together followed by
all the February files and so on.).
BTW, because I use a PC to download the files and MessyDos to transfer
then to AmigaDOS, I have to shorten the filenames to month/year/suffix as I
download them, and this file is madeto handle those shortened file names.
If you download the files directly to your Amiga under their original
names, change all references to "<mo><ye>.lzh" to "Amoslist-<mo><ye>.lzh".
One of the things I found out while going through last winter's mail was
that one of the questions I asked recently has been asked twice before.
Hey, does that make it a Frequently Asked Question? At least it has been
asked more frequently than "What is AMOS?", which is the first question in
the FAQ. (Look Mike, if we didn't know what Amos was we wouldn't be here,
right?)
But now it's time for a Completely Useless Program. Everyone (with a
manual) knows Amos has a command called Load IFF that will load most
pictures in a jiffy or two. Here's a program that does the job in half a
minute (wih a lo-res pic).
'Load-ILBM by Mac Larsson 1988
' AMOSized by Ragnar Fyri 1997
DEMOPIC:
A$=Fsel$("") : Rem filename
B=1 : Rem screen number
T=Timer
LPICILBM[A$,B]
TD=Timer-T
Wait Key
Screen Close B
Print "Operation took";TD;" clicks."
End
Procedure LPICILBM[FILENAME$,SCRN]
Open In 1,FILENAME$
If Input$(1,4)<>"FORM" Then Goto FAIL
A$=Input$(1,4) : If Input$(1,8)<>"ILBMBMHD" Then Goto FAIL
A$=Input$(1,4) : CVI[Input$(1,2)] : WINDX=Param
CVI[Input$(1,2)] : WINDY=Param : A$=Input$(1,4)
DEEP=Asc(Input$(1,1)) : A$=Input$(1,1)
COMP=Asc(Input$(1,1)) : A$=Input$(1,5)
CVI[Input$(1,2)] : MXX=Param : CVI[Input$(1,2)] : MXY=Param
If Input$(1,4)<>"CMAP" Then Goto FAIL
CVL[Input$(1,4)] : NUMCOL=Param : RES=0
If MXX>320 Then Add RES,Hires
If MXY>256 Then Add RES,Laced
Screen Open SCRN,MXX,MXY,2^DEEP,RES
Curs Off : Flash Off : Hide On
Dim CMAP(2),PLANE(DEEP-1)
For A=0 To NUMCOL/3-1
For B=0 To 2
CMAP(B)=(Asc(Input$(1,1)) and 240)
Next
Colour A,(CMAP(0)*16)+CMAP(1)+(CMAP(2)/16)
Next
For A=0 To DEEP-1
PLANE(A)=Leek(Screen Base+A*4)
Next
While BODY<>4
If Instr("BODY",Input$(1,1)) Then BODY=BODY+1 Else BODY=0
Wend : A$=Input$(1,4)
If COMP=0
For A=1 To WINDY
For P=0 To DEEP-1
For B=0 To MXX/8-1 Step 4
CVL[Input$(1,4)] : Loke PLANE(P)+B,Param
Next
PLANE(P)=PLANE(P)+MXX/8
Next
Gosub BREAK
Next
Else
For A=0 To WINDY-1
For B=0 To DEEP-1
SCRROW=PLANE(B)+(A*MXX/8) : C=0
While C<MXX/8
CODEIN=Asc(Input$(1,1))
If CODEIN<128
SCRDATA$=Input$(1,CODEIN+1)
For J=1 To Len(SCRDATA$)
Poke SCRROW+C+J-1,Asc(Mid$(SCRDATA$,J,1))
Next
C=C+CODEIN+1
Else
If CODEIN>128
INBYTE=Asc(Input$(1,1))
For J=C To C+257-CODEIN
Poke SCRROW+J,INBYTE
Next
C=C+257-CODEIN
End If
End If
Wend
Next
Gosub BREAK
Next
End If
Close
Pop Proc
BREAK:
A$=Inkey$ : If A$<>"q" Then Return
FAIL:
Cls : Print "Can't load picture!"
Wait Key
Screen Close SCRN
Edit
End Proc
'
Procedure CVI[BYTES$]
NUMBER=Asc(BYTES$)*256
Add NUMBER,Asc(Right$(BYTES$,1))
End Proc[NUMBER]
'
Procedure CVL[BYTES$]
CVIove" action="http://207.82.250.251/cgi-bin/nextprev">
<input type="hidden" name="disk" value="207.82.250.104_d0">
<input type="hidden" name="login" value="ragnar_fyri">
<input type="hidden" name="f" value="1025">
<input type="hidden" name="curmbox" value="ACTIVE">
<input type="hidden" name="msg" value="MSG09712192">
<input type="hidden" name="js" value="">
<table border=0 cellpadding=0 cellspacing=0 width=498>
<tr>
<td width=76><input type=image name="Move To"
src="http://207.82.250.8/do_move.gif" [Left$(BYTES$,2)] : NUMBER=Param*256^2
CVI[Right$(BYTES$,2)] : Add NUMBER,Param
End Proc[NUMBER]
Those who have been around for a while may remember that AmigaBasic came
with a couple of demo programs that showed how to load and save pictures
using library routines. A bit later one Mac Larsson (see comment line 1)
showed how it could be done entirely in Basic without libraries. I typed in
the programs and experimented a bit with them, then I filed the disk
somewhere and forgot about it. Recently I came across the disk while
looking for someone else and decided to try to convert the programs to Amos
just for fun and to see how fast it would be. AmigaBasic has two functions
called CVI and CVL (ConVert Integer and ConVert Long) that I had to emulate
with procedures. [I tried using Def Fn, but that didn't work!]
As I said, it takes half a minute to do a plain 320*200*16 picture, and
compiling only halves that, so what's the point? Well, you can see the
picture loading and learn a bit about how it's stored (and figure out why
it's called InterLeaved BitMap), and figuring out how it works may help you
understand the file format if you have need for that. (Someone asked about
that once, I think.)
Mac also wrote a couple of programs for saving ILBM files, and for
laoding and saving ACBM (Amiga Continous BitMap), but I haven't tried
converting them yet. One problem with LoadACBM is that it seems to load a
whole bitplane at a time into one st Hi. Just checked out Elevators after
I noticed the title in an old
Amoslist archive. (That's right, it was the name that first attracted my
attention...) It's a nice twist on an old theme with some pretty good
graphics, but there are some details I can't say I like.
It's been ages since I saw a S&L board, but as far as I remember, snakes
would always take you at least one level down and ladders at least one
level up. In your game you move the counters sideways and call itring, and
Amos it looks like Amos can't
handle that, so it needs a major rewrite. BTW, it may be possible to write
faster versions of all the programs simply by loading files into banks and
moving data around with *eek and Copy. Probably is - it's all that string
handling that slows things down...
Talking of things Amos can't handle, I have this big file I tried reading
as a random file, but the program crashed when trying to read record 32769
- that is 32K+1. Can't Amos handle
--====================987654321_0==_
Content-Type: text/plain
--====================987654321_0==_--